METHOD FOR THE EXCHANGE OF DATA BETWEEN CONTROLS OF 
MACHINES, PARTICULARLY ROBOTS 



FIELD OF THE INVENTION 

The invention relates to a method for the exchange of data 
between controls of machines, particularly robots. 

BACKGROUND OF THE INVENTION 

The transmission of data between controls of machines at 
present only takes place by means of direct links, either 
in the form of directly wired inputs and outputs or by 
means of data transmission field bus systems, while com- 
mands or instructions cannot be transmitted in this way. 
Commands must be given by means of operator elements or a 
mainframe computer* The corresponding data are transmitted 
as such directly between the two controls . 

The hitherto known procedure is complicated, because physi- 
cal inputs/outputs or the field bus system must be made 
available. Coincidence must be brought about on both con- 
trols, so that the inputs /outputs have the same signifi- 
cances. As the controls do not normally communicate di- 
rectly via a field bus, but instead by means of an inter- 
posed plant programmable logic control (PLC) , the latter 
must take account of a 1:1 mapping in the inputs/outputs. 
If communication between the controls is to be extended, 
this involves a change to the control programs of the input 
and output configuration (additional field bus words, addi- 



tional lines for physical inputs/outputs, additional pro- 
gramming expenditure on the PLC side) • 

The problem of the invention is to overcome the indicated 
5 disadvantages and in particular permit a simplification and 
simple extendibility of communication between two or more 
controls, whilst largely eliminating fault -prone intermedi- 
ate layers, 

10 SUMMARY OF THE INVENTION 

According to the invention the set problem is solved with a 
method of the aforementioned type, wherein a first control 
produces an instruction to be transmitted with data to be 

15 sent to a second control and with an identification repre- 
senting said second control, wherein the instruction to be 
transmitted is provided with an identification of the first 
control, wherein the first control sends the instruction to 
be transmitted to the second control, wherein the second 

20 control evaluates the data of the instruction and wherein 
the second control supplies an acknowledgement to the first 
control . 

The invention provides a single- line instruction which, 
25 apart from the actual data to be transmitted (physical 

states and/or control commands) comprises an identification 
of the receiver control- This creates simple extendibility 
of the communication by freely programmable commands as pa- 
rameters of the control instruction (string commands) , so 
30 that an increased transparency is possible in the user pro- 
gram by the use of freely programmable commands as parame- 
ters of the instructions and therefore the use of corre- 
sponding names for the commands instead of I/O designa- 
tions. The invention makes extendibility very simple, be- 
35 cause it is only necessary to declare a new global vari- 




able, which can then be used on the receiver control, be- 
cause the latter can manipulate a random global variable. 
Extendibility is not limited by hardware resources. Apart 
from data, i.e. in particular physical states, it is possi- 
5 ble to also transmit commands in this way. As a result of 
the invention data and command transmission to robots can 
take place flexibly without hardware/software expenditure 
on exchanging robots and without fixing a hierarchy, which 
is a prerequisite for direct cooperation of balanced ro- 

10 bots. A further advantage is that the transmission takes 
place synchronously, so that the transmission initiator 
gains a direct acknowledgement concerning the result of the 
action and can only continue to operate when the command is 
performed on the other side. According to the invention, 

15 not only simple data can be transmitted, by means of a 

value allocation, but in targeted manner system states can 
be manipulated, such as the forcing o£ a step operating 
mode or the performance of a set selection in the other 
program • 

20 

According to a preferred development of the invention, the 
command to be transmitted is formatted as a UDP message and 
in particular the acknowledgement of the second control is 
also formatted as a UDP message. According to further de- 

25 velopments of the invention, the second control compiles 

the data received in an internal code and in particular, if 
the transmitted data contain a control command, the second 
control executes the same. Finally, according to the in- 
vention, the first control only transmits an instruction to 

3 0 be transmitted to a further control on receiving therefrom 
an acknowledgement to the effect that the second control is 
ready to perform an instruction. The instruction to be 
transmitted can also contain the identification of the con- 
trol in question and also the data to be transmitted in the 

35 form of a constant or variable. 



BRIEF DESCRIPTION OF THE DRAWINGS 

Further advantages and features of the invention can be 
5 gathered from the claims and the following description of 
an embodiment of the invention with reference to the at- 
tached drawings, wherein show: 

Fig, 1 A diagrammatic representation of several 

10 mutually cooperating controls. 

Fig. 2 The fundamental sequence of the method 

according to the invention for exchanging data 
between two controls. 
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Fig. 3 A more precise representation of the process- 

ing of the data to be exchanged between 
controls in the same. 



DETAILED DESCRIPTION OF THE DRAWINGS 



Fig. 1 shows in exemplified manner four cooperating con- 
trols 1 to 4 with each of which is associated a clear ad- 

25 dress, IP= W 192* 0.1.1" for control 1. Each control 1 to 4 
has a computer 1.1 on which runs a control program for a 
machine, particularly for a robot controlled by the par- 
ticular control. Each control also has an ethernet driver 
1.2 to 4.2 and a network card 1.3 to 4.3 for communication 

30 with a network 5, by means of which the controls 1 to 4 are 
interconnected directly or by means of a switch. The memo- 
ries contained in a control, such as read-only memories, 
volatile memories, etc., as well as peripherals, such as in 
particular input and output devices, are not shown. 



For data exchange purposes between two controls 1 and 2, 
initially a control program running on the first control 
produces an instruction to be transmitted, which on the one 
5 hand includes the data to be transmitted, such as physical 
parameters of the robot associated with the first control 
or also instructions £or modifying physical parameters in a 
robot associated with the second control. The instruction 
to be transmitted also includes the address of the control 

10 to which the data or instructions produced by the program 
running on the first computer are to be transmitted. In 
addition, said instruction is provided with the sender's 
own address. This message is then transmitted as a UDP 
message via the network to the second control (fig- 2) . 

15 The latter receives the UDP message and then compiles the 
command to an internal control code. In the embodiment of 
fig. 2, the interpreter of the control software running in 
the control 2 executes the command transmitted to it, 
namely 1=1+1, i.e., increase by a value of "1" the physical 

20 quantity I. Then the control 2 produces an acknowledgement 
information, which on the one hand contains the address of 
the first control and on the other a statement concerning 
the performance result of the received and executed in- 
struction. This message is sent back as a UDP message from 

25 control 2 to control 1, whose interpreter waits for this 
command response, received by the first control and evalu- 
ated by the control program of the first control and as a 
result of the evaluation optionally further instructions 
are sent by the first control to the second control. 

30 

In this and also in the example of fig. 3 the control 1 
acts as a server / whereas control 2 (or also control 3) op- 
erates as a client. Associations are not fixed and can in- 
stead be modified as a function of the tasks to be per- 
35 formed. 



Before the control 1 sends a command to another control, 
control 2 and/or 3 in fig. 3, control 1 initially waits for 
controls 2 and 3 to perform their tasks, optionally based 
5 on a remote control command and give a corresponding ac- 
knowledgement, as. explained in connection with fig. 2. 
Then a new command sequence is transmitted to the controls, 
namely to weld and to fetch a part. 

10 Further remote control commands can follow. The control 
then again waits until the controls 2 and 3 {clients 1 and 
2) have given an acknowledgement about the performance of 
the transmitted responses. 

15 Controls 2 and 3 (clients 1 and 2) wait for a task, execute 
the commands received (weld/ fetch) and then return to the 
idle/waiting state. 

The address of the particular control can be used as a con- 
20 stant (e.g. RemoteCmd ("192.0.1.3", ...)) or as a variable 
(e.g. IP[]="192.0.1.2 H RemoteCmd (IP [] , .,.)). The same ap- 
plies regarding the data to be transmitted, which can also 
be fully used as a constant (RemoteCmd (... , "MyVar=44 " ) ) or 
a variable (CmdString [] ="MyVar-055 n , RemoteCmd ( . . . , 
25 CmdString []) ) . 

Standard commands are the selection of a program on the 
control in question (RUNProgNameO ) , the resetting of a 
program (RESET) , the cancellation of a program (CANCEL) and 

30 the allocation of a value to a global variable (value allo- 
cation) as simple values, strings or Boolean values or also 
in the form of complex allocations, such as sums, 
smaller/larger estimates and complex functions. Finally, a 
further possible command involves the waiting for a spe- 

35 cific system state for the controlled control, such as e.g. 



the value of an input X becoming equal to that of an input 
2: RemoteCmddPU; "Wait for $IN[l]==$rNf2] ») . 
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LIST OF REFERENCE NUMERALS 



10 

!-4 Controls 

1 • 1 Computer 

1-2-4.2 Ethernet drivers 

1*3-4.3 Network cards 

15 5 Network 



